Detection of Synchronization Errors through Speculative Lock Elision

The idea of executing sections of code optimistically in parallel in order to increase performance has recently regained popularity in the computer architecture literature. Two papers [6, 7] suggest the speculative elision of lock acquisitions in threaded programs to eliminate unnecessary serialization and to allow the use of more coarse-grained locks without sacrificing performance. These schemes rely primarily on extensions to processor caching mechanisms, an idea introduced in [4]. This paper suggests a minor extension to such a protocol [7] to enable production-time detection and localization of synchronization errors in threaded applications. Although the idea may also apply to some earlier techniques [3], its value has not been previously recognized. The closest related work in terms of detecting synchronization errors is Eraser [8], which seems more likely to detect errors, but slows applications down by about a factor of ten, and is thus not practical outside of the application development environment. Similar techniques have also been proposed for data race detection with release consistency [2]. Background: Databases require concurrent execution of transactions to achieve high performance, but transactions must be executed in a mutually atomic fashion to avoid introducing inconsistencies in the form of non-serializable data dependencies between transactions. The need for transaction rollback in the face of deadlock led to the view of a transaction as a lock acquisition phase followed by a lock release phase [1]. Later work, which coined the term “optimistic concurrency” [5], proposed a three-phase view consisting of reads, validation of reads, and writes. The latter two phases in this model must be performed atomically, with execution of the write phase (commit) being predicated on successful completion of the validation phase. Notions of read and write sets were introduced to track accesses by each transaction for use in detecting conflicts. The application of processor caching mechanisms to optimistic concurrency first appeared in the context of automatic parallelization of LISP code [4]. The sequential code was split into a totally ordered set of fragments, with each fragment containing only a few writes to memory. Unlike database transactions, such code fragments must obey the ordering implied by sequential execution. Two caches associated with each processor held the read and write sets for currently executing fragments. When a fragment completed in sequential order, its write set was broadcast to other processors across a bus, restarting later fragments that had used any previous value optimistically. One of the first computer architecture schemes to support explicitly parallel transactions was Transactional Memory [3], which extended the instruction set to support transaction semantics. New instructions included transactional reads and writes, a validate instruction to confirm the continued accuracy of all transactional reads, and a commit instruction to validate and complete a transaction when possible. The paper also outlined a possible implementation, which for practical reasons added a second cache to hold the read and write sets apart from the normal cache data. The design also extended the cache coherence protocol to convey the difference between transactional and nontransactional accesses, allowing a processor to restart a remote transaction by refusing to share transaction data. Speculative Lock Elision: Many modern, highperformance processors support speculative execution of instructions in hardware to enable branch prediction. Recently, two papers [6, 7] suggested the use of this speculative mode to support optimistic execution of critical sections protected by locks, a technique termed speculative lock elision, or SLE. We build on [7], which allows execution to pass acquisition of an unowned lock without actually claiming the lock by placing the processor into speculative execution mode. The approach is logically equivalent to that used with Transactional Memory [3], but uses hardware speculation for rollback and restart rather than explicit software control. The support of mutual exclusion (lock) semantics rather than atomicity (transaction) semantics has implications for both programmers and for the system. Atomicity is more attractive than mutual exclusion from a programming point of view, as atomicity is a more local phenomenon that need not be rethought—or, in many cases, even understood—by programmers extending an application. In contrast, use of mutual exclusion must be managed carefully to avoid deadlock, and the strategy used for each abstraction must generally be understood by every programmer that extends or builds upon the abstraction. Outside of the database community, however, mutual exclusion is more common in practice because locks are more widely and directly supported by both hardware and software than are transactions. From a hardware implementor’s point of view, SLE offers advantages over optimistic transactions. With SLE, a natural backoff mechanism is available to eliminate the possibility of starvation. In particular, repeated failures of speculative elision cause the processor to acquire the lock nonspeculatively [7], guaranteeing forward progress for correct